When developing software applications, developers may employ automated testing tools that exercise functionality of software applications with minimal or no user input from a human during the testing cycle. Automated testing tools may employ Application Programming Interfaces (APIs) provided by applications and operating systems to send commands to the software application being tested, in order to interact with the software application (e.g., to select menu options, to provide textual input, to press buttons, etc.). For example, when developing a web-based software application (web application), a developer may employ automated testing tools that utilize APIs of a web browser to interact with the web application. For example, automated testing tools may utilize web browser APIs to select Hypertext Markup Language (HTML) links, to interact with popup dialogue boxes, to provide textual input to text fields, etc.
Frequently, web applications include authentication mechanisms. For example, an e-mail web application may request user authentication before granting access to the e-mail web application. The request for user authentication may cause a web browser to display a popup authentication dialogue, which includes fields for a user to provide user credentials (e.g., username and password) and one or more buttons (e.g., for submitting the user credentials, for dismissing the dialogue, etc.). To authenticate, a user would typically provide user credentials and select a button for submitting the credentials, which would result in access to e-mail web application if the user credentials are valid. Accordingly, automated testing of web applications may involve dealing with authentication that involves use of popup authentication dialogues.
One way to perform authentication during automated testing involves providing a “back door” into the web application. For example, a developer may include functionality for accessing the web application in a manner that bypasses user authentication. However, since inclusion of back doors introduces a significant security risk, developers may include the back door only in a testing version of the web application. This means that the developer must maintain at least two separate versions of the web application, including the testing version and a “live” version. This also means that automated testing tools only test the testing version of the web application, and not the live version that is actually deployed.
Another way to perform authentication during automated testing is to include functionality in the automated testing tools for automatically supplying user credentials in any authentication dialogues that are displayed by a web browser. For example, an automated testing tool may be programmed to provide a particular username in a “username” field of an authentication dialogue, to provide a particular password in a “password” field of the dialogue, and to press an “ok” button of the dialogue. However, different web browsers display authentication dialogues in different ways. For example, an authentication dialogue from one web browser may include a “username” and a “password” field along with a “submit” and a “cancel” button, while an authentication dialogue from another web browser may include an “account name” and a “passphrase” field along with an “ok” and a “dismiss” button. In addition, different web browsers may provide different APIs for interacting with authentication dialogues. Each type of web browser may even change the way it presents authentication dialogues from version to version. As such, programming automated testing tools to automate use of authentication dialogues can be difficult, especially when supporting a broad range of web browsers and a large number of versions of the web browsers.